Health Financing

Health financing information systems handle enrolment, eligibility, claims and provider payment. They are frequently built in isolation from clinical systems, and the isolation is expensive on both sides: claims are submitted with data that already exists in the EMR, and clinical systems have no visibility of coverage.

This domain also introduces a dynamic absent elsewhere in health architecture: money changes what gets recorded. Designing for that is part of the job.

---

The core flows

   Enrolment          Person → scheme membership, contributions, dependants
        │
   Eligibility        "Is this person covered, for this service, today?"
        │             ← checked at the point of care, synchronously
   Service delivery   Clinical encounter
        │
   Claim              Provider → payer: services, diagnoses, costs
        │
   Adjudication       Validate, price, approve, partially approve, reject
        │
   Payment            Payer → provider, with a remittance advice
        │
   Reconciliation     Provider matches payments to claims

Each arrow is an integration point, and each has a different latency requirement. Eligibility must answer in seconds at a registration desk; claims processing can take days.

---

Eligibility checking

The most valuable and most demanding integration.

Requirements:

• Fast, because a queue is forming
• Available, because an outage blocks service or forces providers to treat and hope
• A defined fallback: what does the provider do when the check fails? Treat and claim retrospectively, or deny? This is a policy decision with real consequences for patients, and it must be made explicitly rather than being determined by whatever the software does on timeout.
• Identity-dependent — eligibility is checked against a person, so it depends entirely on the client registry or the national identity system

FHIR: CoverageEligibilityRequest / CoverageEligibilityResponse, Coverage.

Design note. Cache eligibility responses at the facility with a short, defined validity, so a brief outage does not stop registration. Record which response was relied upon, so retrospective disputes can be resolved.

---

Claims

A claim asserts: this person, this provider, these services, these diagnoses, this cost.

What it needs from the rest of the architecture:

Requirement	Source
Verified client identity	Client registry
Verified provider and facility	HWR, facility registry
Coded diagnoses	ICD, bound to a value set
Coded services or procedures	National procedure/service list; sometimes a benefit package code
Tariffs	Benefit package and price schedule, versioned by effective date
Clinical evidence	Where adjudication requires it — and this is where consent becomes sharp

Adjudication applies rules: is the service in the benefit package, was pre-authorisation required, is the price correct, are there duplicates, does the diagnosis support the procedure, has the annual limit been reached?

FHIR: Claim, ClaimResponse, ExplanationOfBenefit. Many national systems use local formats or X12 (in the US); FHIR's financial module is well developed but adoption for national claims varies.

---

The clinical–billing boundary

The most important architectural principle in this domain.

An insurer's need to verify a claim is not the same purpose of use as a clinician's need to treat. Sending the full clinical record with every claim is disproportionate, and in many jurisdictions unlawful.

Design accordingly:

• Claims carry coded summary data, not the clinical record
• Supporting clinical evidence is requested only for claims selected for review, with the request and the disclosure both audited
• The purpose of use is recorded on every access; see consent and trust
• Access by payers is scoped, time-limited and reviewable

The incentive problem

Where the same coded data drives both clinical care and reimbursement, the reimbursement incentive shapes the clinical record. This is well documented and predictable — coding drifts toward whatever is better remunerated, and the clinical record becomes less useful for care and for epidemiology.

Architectural mitigations are partial but worth implementing:

• Keep the clinical assertion and the billing assertion distinguishable, with provenance on both. A diagnosis recorded by the treating clinician and a diagnosis added by a coder for billing are different facts.
• Do not let the billing code overwrite the clinical code. Map between them; retain both.
• Monitor coding distributions over time and across providers. Sudden shifts are a signal.

This is a governance problem the architecture can support or undermine, and it is easier to support at design time than to remediate later.

---

Provider payment models

The payment model determines what data the system must capture, which is why it is an architectural input rather than a purely financial decision.

Model	Payment based on	Data required	Behavioural effect
Fee for service	Each service delivered	Itemised service records	Encourages volume
Capitation	Registered population	An accurate registered population list	Encourages under-provision; needs quality monitoring
Case-based (DRG)	Diagnosis-related group per admission	Coded diagnoses and procedures, length of stay	Encourages coding intensity
Global budget	Period allocation	Aggregate activity	Simple; weakly linked to need
Performance-based	Achievement of indicators	Verified indicator data	Encourages gaming of the measured indicators

Capitation in particular imposes a hard requirement: an accurate, non-duplicated, current registered population per provider — which brings the client registry and its duplicate rate directly into the payment path. A 10% duplicate rate is a 10% payment error.

---

Integration with clinical systems

The valuable integrations, in order of practical benefit:

1. Eligibility at registration — the provider knows the patient is covered before treating
2. Claim generation from the encounter — services and diagnoses already recorded in the EMR populate the claim, removing double entry and transcription error
3. Pre-authorisation in workflow — requested and answered without leaving the clinical system
4. Remittance back to the provider's system — so reconciliation is not manual

Integration 2 is where most of the efficiency is, and where the incentive problem above must be managed.

---

Platforms

Platform	Notes	Licence
openIMIS	Open-source insurance management system for developing countries: enrolment, claims, provider management	AGPL
DHIS2	Sometimes used for aggregate financing indicators; not a claims system	BSD
National scheme systems	Most national insurers run bespoke or commercial systems	Varies

openIMIS is the most established open-source option in this space and has an active implementation community. Verify current status; see platforms.

---

Checklist

• Eligibility check integrated at registration, with a defined and published fallback on failure
• Client identity resolved through the client registry; duplicate rate monitored, because it is a payment error rate
• Provider and facility verified against the registries
• Diagnosis and service coding bound to versioned national value sets
• Tariffs versioned with effective dates
• Claims carry coded summary; clinical evidence requested only on review, and audited
• Purpose of use recorded and enforced for payer access
• Clinical and billing assertions distinguishable, with provenance
• Coding distributions monitored for drift
• Remittance flows back to the provider's system
• Payment model's data requirements explicitly supported

---

References

• openIMIS — https://openimis.org/
• FHIR financial module — https://hl7.org/fhir/financial-module.html
• FHIR Coverage — https://hl7.org/fhir/coverage.html
• FHIR Claim — https://hl7.org/fhir/claim.html
• WHO health financing — https://www.who.int/health-topics/health-financing